|
|
|
Put an Undo shortcut onto your pop-up memo in a Tmemo to make it easier to access than the usual Undo command (Ctrl+Z). Here's how to insert it:
Memo1.Perform(EM_UNDO, 0, 0);
To check whether undo is available so you can enable/disable an undo menu item:
Undo1.Enabled := Memo1.Perform(EM_CANUNDO, 0, 0) <> 0;
You can bring up the WinHelp Search dialog for your application's help file by using TApplication's HelComm method to send the Help_PartialKey command to the WinHelp system. Use a PChar paramater for this command. The following example uses an empty string, invoking the Search dialog and leaving the edit control in the dialog empty:
procedure TForm1.SearchHelp;
var
P: PChar;
begin
Application.HelpFile := 'c:\delphi\bin\delphi.hlp';
P := StrNew('');
Application.HelpCommand(Help_PartialKey, longint(P));
StrDispose(P);
end;
To print all the lines within a TMemo or TListbox component, use the following function. It accepts a TStrings object as a paramter and prints out each string to the default printer. The function will work with any type of component that contains a TStrings-type property, such as a TDBMemo or TOutline.
uses Printers;
procedure PrintStrings(Strings: TStrings);
var
Prn: TextFile;
i: word;
begin
AssignPrn(Prn);
try
Rewrite(Prn);
try
for i := 0 to Strings.Count - 1 do
writeln(Prn, Strings.Strings[i]);
finally
CloseFile(Prn);
end;
except
on EInOutError do
MessageDlg('Error Printing text.', mtError, [mbOk], 0);
end;
end;
To print out the contents of a TMemo or TListbox, use the following
code:
PrintStrings(Memo1.Lines);
or
PrintStrings(Listbox1.Items);
All your text doesn't have to be the same color in a TBDGrid. You can make text in one column a different color than the text in the rest of the grid. Set the Default Drawing property of Grid(s) to False.
procedure TForm1.DBGrid1DrawDataCell(Sender: TObject; const Rect: TRect;
Field: TField; State: TGridDrawState);
begin
{ if field name is "NAME" }
if Field.FieldName = 'NAME' then
{ change font color to red }
(Sender as TDBGrid).Canvas.Font.Color := clRed;
{ draw text in the grid }
(Sender as TDBGrid).Canvas.TextRect(Rect, Rect.Left + 2, Rect.Top + 2,
Field.AsString);
end;
To remove the vertical scrollbar from a TBDGrid component, override its Paint method. Inside the Paint method, call the SetScrollRange API procedure to set the minumum and maximum scroll values to zero. This disables the scrollbar. Next, call the inherited Paint by using the code below. It contains a new component called TNoVertScrollDBGrid. You can copy the code into a file called NEWGRID.PAS, and add it as a custom component to your component library.
unit Newgrid;
interface
uses
WinTypes, WinProcs, Classes, DBGrids;
type
TNoVertScrollDBGrid = class(TDBGrid)
protected
procedure Paint; override;
end;
procedure Register;
implementation
procedure TNoVertScrollDBGrid.Paint;
begin
SetScrollRange(Self.Handle, SB_VERT, 0, 0, False);
inherited Paint;
end;
procedure Register;
begin
RegisterComponents('Data Controls', [TNoVertScrollDBGrid]);
end;
end.
Experienced VB developers have always edited their AUTOLOAD.MAK file using a text editor to remove all the unused controls Microsoft put there to fill up the toolbar. All of these controls load into memory every time your app starts. By removing everything you don't need, you can see exactly what's in your project. It's more important to clean out your unused controls in Visual Basic 4.0 because they no longer appear in the Project window and you can easily forget about them.
A mixed-case, prefix-based naming system makes the most sense with VB. For example, you might reference the caption of a label as:
frmMain.lblTitle.Caption
and a module-scoped integer used as a counter as:
miCounter
Microsoft removed scoping limitations that existed under VB 3.0 Now you can have Public (previously called Global) and Private variables and subroutines in form *and* code modules. Subroutines default to Public and variables default to Private. (When you use a Public variable in a procedure you should put the declaration at the beginning of the procedure.)
In previous versions of VB, it was impossible to have duplicate globally scoped procedure names. That's why you could not reference forms globally. VB 4.0 allows duplicate procedure names, which you call by prefixing the module as below:
Module1.DoStuff
or in the case of a form:
Form1.Form_Load
One of the major concepts behind object orientation is the use of classes to encapsulate functionality. Class objects have properties and methods, just like other objects. Class properties are implemented using variables: They can be Public or Private and can execute property procedures when examined or changed. Class methods are implemented using already-familiar subroutines. The entire class can even be made public, in which case external applications can call it through OLE automation and create class objects they can manipulate.
If you use classes to create custom objects you should consider grouping those objects into a collection. Collections provide a flexible method for adding and deleting members and for iterating over the collection's members. You can implement collections by using the new built-in Collection data type or a custom collection class.
On a multibyte operating system each individual character occupies multiple bytes in memory. While 16-bit VB uses single-byte ANSI strings, 32-bit VB uses Unicode (a multibyte character system) strings internally. VB 4.0 introduces the Byte data type that occupies 1 byte in memory in either 16-bit or 32-bit VB. VB 4.0 also includes byte versions of familiar string functions--Len, Left, Right and Mid--for use with Byte data. For example, LenB returns the number of bytes used to represent that string instead of the number of characters in a string.
In addition to the pictures and icons you can embed in VB forms, VB 4.0 now provides built-in support for traditional Windows string, picture, and binary data resources. While these resources can be loaded using direct calls to the Windows API, the VB 4.0 LoadResString, LoadResPicture, it's much easier to load them with LoadResData functions. LoadResData functions also help reduce platform-dependent API declarations and code.
VB 4.0 only allows one resource file in a project; if you want more, you'll have to put them in a conventional DLL or EXE and access them using the Windows API.
The ability to create an OLE DLL out of a VB program, added late in the development cycle, is one of VB 4.0's most powerful features. When implemented locally, it can reduce cross-process communications overhead. But OLE DLLs were really designed for remote operations under Windows NT. In terms of system resources, processes are expensive, but in-process DLLs are cheap in NT. A remote server running under NT could conceivably load 100 OLE DLLs, but would run out of steam with only a few dozen separate processes.
VB 4.0 allows you to create both OLE automation controllers *and* servers. This dual functionality lets you link two programs together so that one program can trigger code (for example, call back into a procedure) in the other. OLE callbacks enable asynchronous operation in VB applications. Processing can be handed off to another program, which then calls back into the first program when finished. After invoking the second program, the first program's code is not blocked. It continues to execute and have a responsive user interface. Because VB 4.0 applications are single-threaded, OLE callbacks make little sense with an in-process OLE DLL. Use them when programs run as separate processes (and thus have separate threads in Win32). They are even more useful when the second program runs on a remote machine using the features of the Enterprise Edition.
VB 4.0 makes extensive use of the system registry not only for VB itself but for all OLE controls and OLE automation components. In addition, modifying registry pointers is the core technique behind the remote automation the Enterprise Edition makes possible. Fortunately, OLE controls are self-registering, VB automatically handles the registration issues for VB-created OLE automation servers and the VB Setup Wizard takes care of modifying users' registration databases. To know what's going on behind the scenes, developers must rely on RegEdit for Windows 3.1 and Win95 and RegEdt32 for NT.
Type libraries contain detailed information about the objects you can create and manipulate through OLE automation. Type libraries have two main advantages: they provide design-time syntax information to the development environment and early-binding to specific object types. VB 4.0 automatically creates type libraries and embeds them within the application's executable for any objects that exposed via OLE automation. It's also possible to manually create a type library by using the MkTypLib utility to create a standalone type library or by including a specialized Object Description Language (ODL) file as part of a 32-bit VC++ project.
This code is often used for idle-time processing but it has a non-trivial impact on system performance and causes reentrant problem in some situations. Under 32-bit Windows it's better to loop normally and use the Win-32 Sleep function.
If you plan to develop VB 4.0 code for Win16 and Win32 platforms, you have to encapsulate operating system differences in different code paths and make use of VB 4.0's new conditional compilation where Win16 and Win32 tokens are predefined. A more common use of conditional compilation is for debug and test code. By setting a single token you can compile an executable that can be customized for three situations: running in the design environment, as a compiled debug version for testers and as a compiled release version for distribution to users.
When accessing functions in a DLL, VB assumes that all functions use the Windows API calling convention. When calling DLLs, 16-bit VB uses the Pascal calling convention and 32-bit VB uses the stdcall calling convention. You can't access cdecl functions in a DLL.
Because the system word size on a 32-bit operating system is equal to a VB Long data type, VB Integers are rare as parameters or return values in the Win32 API (though they are often packed into structures handled as user-defined types in VB). Also, because parameters must be aligned to 32-bit addresses, there's no performance advantage anyway to using VB Integers as parameters. Thus, an "as Integer" in a 32-bit declaration is most likely a mistake that needs correcting.
If you're building large applications that comprise several components--either as traditional executables or as new OLE DLLs--you'll want to take advantage of VB's command-line compilation to keep everything in synch. Simply create a batch file with each of the projects and any associated conditional compilation tokens.
Develop Under NT
Developers using VB 4.0 should develop under Windows NT. Develop components initially as separate processes on the local machine to take advantage of the new multi-instancing capabilities of the VB 4.0 Integrated Development Environment (IDE). After everything is running and debugged as separate processes, recompile components with substantial inter-process communication as OLE DLLs (OLE in-process servers). Also, components that are to be distributed to remote servers can be migrated there. Finally, test the programs and components on other platforms.
Because VB 4.0 is heavily based on OLE, the OLE system DLLs must reside on any system that attempts to run a VB 4.0 application. While these DLLs are redistributable in 16-bit Windows, they're actually shipped with Windows 95 and NT, and 32-bit applications will *never* install or update them. Also, since the 32-bit versions of the OLE DLLs provide the thunking necessary for 16-bit and 32-bit OLE applications to communicate, 16-bit OLE-based applications should *not* install the OLE system DLLs under Win95 or NT. No 16-bit VB 4.0 apps will run under versions of NT prior to 3.51.
In previous versions of VB, the Setup Wizard had a well-known reputation for being, er, much less than ideal. But not only is VB 4.0's Setup Wizard more robust, it incorporates all the new OLE-related functionality required of any VB 4.0 app. It's the *only* method available for distributing the remote applications built with the Enterprise Edition.
|
|
|